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METHOD AND COMPUTER SYSTEM FOR SCHEDULE TRADING 

BACKGROUND OF THE INVENTION 

Technical Field 

The invention relates generally to employee scheduling 
5 and, more particularly, to enable employees to trade scheduled 
shifts . 

Description of the Related Art 

Employees, assigned specific work schedules, often need 
to trade their schedules with other employees. This can be 

10 for a variety of reasons, such as for personal reasons or to 
fulfill family obligations. 

A trade means that the employee is offering a specific 
set of one or more scheduled shifts in exchange for a set of 
desired shifts. Traditionally, for a trade to occur between 

15 two employees, a first employee must try and locate a second 
employee who (a) has been scheduled to work the shifts that 
the first employee desires (b) is interested in trading those 
set of shifts, and (c) is interested in working the set of 
shifts that the first employee is scheduled to work. All 

20 three conditions must be met before two employees can take 
their trade to a supervisor for approval. 

If specific skills, such as being bilingual, are required 
to work the shifts, a supervisor must then ensure that both 
the first employee and second employee have the necessary 

25 qualifications to work each other's shifts, prior to approving 
the trade. 

Typically therefore, employee schedule trading is a 
tedious, manual, and often frustrating process for employees 
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and for their supervisor. Therefore, there is a need for an 
improved method of trading employee schedules on-line. 
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BRIEF SUMMARY OP THE INVENTION 

It is an object of the invention to enable given entities 
(e.g., employees, agents, contractors, or others) to trade 
work schedules online, thereby reducing paperwork and 
5 administration. 

It is a more specific object of the invention to allow 
such entities to trade schedules online, preferably according 
to rules defined by a supervisor. 

It is yet another more specific object of the invention 
10 to provide a work schedule trading forum. To request a trade, 
an agent preferably posts his or her schedule to an online 
trade board and indicates what he or she would like in return 
for that schedule. Preferably, another agent is then able to 
accept the posted schedule, for example, if he or she has a 
15 schedule that matches the posting agent's request, and if all 
other supervisor- imposed constraints are otherwise met. 

It is still another more specific object to provide for 
such a scheduling trading forum where trades may be approved 
automatically or by a supervisor, depending on supervisor - 
20 imposed rules or other policies. Once a given trade is 
approved, preferably the entity schedules are traded 
automatically. 

A further object of the invention is to provide a 
computer- implemented method of work schedule trading. It 
25 enables a pair of entities, each of whom has a schedule that 
the other wants, to find each other and to conduct a trade 
easily and efficiently. The invention provides an online 
trade board where entities can see what trades have been 
posted, or post their own trade requests, without having to 
3 0 search for another entity with whom to trade. 
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It is another object of the invention to enable entities 
to post any scheduled workday or time period for trading to a 
virtual "bulletin board . " 

It is a further object of the invention to enable agents 
5 to view their work schedule trade history, including trades 
that are pending, completed, unsuccessful, or canceled. 
Agents preferably receive alerts, notifying them of their 
trade results. 

It is still another object of the invention to enable 
10 entities that ability to view all or some posted schedules on 
the bulletin board, or only those schedules that "match" their 
schedules. 

Yet another object of the invention is to provide a 
scheduling trading system that enables contact center agents 
15 can stay at their desk, ready to handle a next contact while 
looking for a posted trade, or posting a trade, instead of 
leaving their workspace to go to a bulletin board to look for 
a trade. 

It is another object of the invention to implement a work 
20 scheduling trading function in a distributed computer 

networking environment that uses flexible work rules that are 
preferably established by a supervisor entity. Preferably, 
the rules are customized and govern various trading criteria. 
For example, to ensure adequate coverage, an administrator may 
25 set a trading rule that requires agents trading schedules to 
have the same skills. Additionally, a workplace manager can 
establish rules to disallow certain agents from trading 
schedules. Other trade rules that can be implemented include, 
for example: a minimum advance notice required, in hours, a 
3 0 maximum advance notice allowed, in days, a minimum amount of 
time that may be traded, in hours, a maximum amount of time 
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that may be traded (per some given time period) , a requirement 
that trade schedules must fall within a configurable number of 
weeks (or within the same week) , a requirement that trade 
schedules must fall in the same calendar month or other user- 
5 defined pay period, a requirement that trades may not produce 
overtime for agents, a requirement that certain trades require 
supervisor approval or be approved automatically, a 
requirement that agents must be in the same agent group, a 
requirement that agents must have the same skills, a 

10 requirement that agents must belong to the same group (e.g., 
full-time agents might only be allowed to trade with other 
full-time agents) , a permission that agents are allowed to 
give away time, a permission that agents are allowed to trade 
partial schedules, and the like. 

15 The foregoing has outlined some of the more pertinent 

features of the invention. These features should be construed 
to be merely illustrative. Many other beneficial results can 
be attained by applying the disclosed invention in a different 
manner or by modifying the invention as will be described. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present 
invention and the advantages thereof, reference is now made to 
the following descriptions taken in conjunction with the 
5 accompanying drawings, in which: 

FIGURE 1 is a block diagram of an illustrative trading 
rules display according to an embodiment of the invention; 

FIGURE 2 is an illustrative trade board display rules 
display according to an embodiment of the invention; 
10 FIGURE 3 is an illustrative agent permissions display 

according to an embodiment of the invention; 

FIGURE 4 is an illustrative supervisor approval display 
according to an embodiment of the invention; 

FIGURE 5 is an illustrative agent "wants to trade" 
15 schedule display according to an embodiment of the invention; 

FIGURE 6 is an illustrative agent "wants in return" 
schedule display according to an embodiment of the invention; 

FIGURE 7 is an illustrative agent trade requests display 
according to the invention; 
20 FIGURE 8 is an illustrative trade board display according 

to an embodiment of the invention; 

FIGURE 9 is an illustrative trade details display 
according to an embodiment of the invention; 

FIGURE 10 is an illustrative confirm trades display 
25 according to an embodiment of the invention; 

FIGURE 11 is a block diagram of a computer system in 
which the present invention may be implemented; and 

FIGURE 12 is a flowchart showing a functional overview of 
an illustrative embodiment of the present invention; 
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DETAILED DESCRIPTION OF AN EMBODIMENT 

In the following discussion, the invention is described 
in the context of a contact center environment, although it 
should be understood that the invention can be practiced in 
5 other types of environments such as, without limitation, sales 
force environments, field service environments, manufacturing 
environments, and other types of environments wherein entities 
(agents, employees, contractors, other persons, etc.) work 
according to assigned schedules. In a contact center, the 

10 environment generally comprises an automatic call distributer 
(ACD) and a multimedia server coupled to a host computer via a 
computer network. The ACD and multimedia server generally 
provide routing capabilities for incoming voice calls (via the 
ACD) and other contacts (via the multimedia server) , such as 

15 faxes, email, voice mail, web requests, we call -back requests, 
web chats, web voice calls, web video calls, and the like. 
For ease of discussion, the persons who work at the contact 
center are referred to herein variously as "agents" or 
"employees . " These designations are used interchangeably 

2 0 within the following description. Of course, this 

nomenclature is not meant to be taken to limit the invention 
in any way, as the word "employee" or the word "agent" is 
meant to be broadly construed to include any person regardless 
of a particular legal status. An entity need not actually 

25 handle contacts, of course. A "schedule" is any ordered list 
of times at which given events or activities are planned to 
occur. Of course, as noted above, the present invention may 
be implemented in any work environment where entities desire 
to trade work or other task schedules. 

30 As seen in Figure 12, a distributed computing environment 

in which the schedule trading method and system of the 
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invention may be implemented includes a set of computing- 
related entities (systems, machines, processes, programs, 
libraries, functions, or the like) that facilitate or provide 
an agent -supervisor network. In a typical implementation, the 
5 environment typically comprises a set of computers. A 

representative machine is a client workstation or a network- 
based server running commodity (e.g. Pentium-class) hardware, 
an operating system (e.g., Linux, Windows 2000, OS-X, or the 
like), an application runtime environment (e.g., Java), and a 

10 set of applications or processes (e.g., Java applets or 
servlets, linkable libraries, native code, or the like, 
depending on platform) that provide the functionality of a 
given system or subsystem. A client machine typically 
includes a Web browser (Internet Explorer, Netscape Navigator, 

15 Apple Safari, or the like) or other rendering engine. A Web 
browser typically includes or supports media players and other 
plug-ins. The present invention implements a distributed 
platform that enables employees to trade schedules over a 
network including, without limitation, the publicly- routable 

20 Internet, a corporate intranet, a private network, or any 
combination thereof. The method may be implemented as a 
standalone product, or as a managed service offering. 
Moreover, the method may be implemented at a single site, or 
across a set of locations. 

25 It is further noted that, unless indicated otherwise, all 

functions described herein may be performed in either hardware 
or software, or any combination thereof. In a preferred 
embodiment, the functions are performed by one or more 
processors executing given software. 

3 0 In illustrative agent -supervisor network 1200, a central 

database 1202 is used to store data comprising a "trading 
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board," which will be illustrated in more detail below. The 
trading board may be accessed by an agent or a supervisor. As 
will be described, the trading board is accessed and modified 
by one or more machines, such as a supervisor machine 1204, 
5 entity A 1206, entity B 1208, entity C 1210 and entity D 1212. 
In this example, only four entities are shown, but in a 
typical implementation, there will be many more depending on 
the number of entities at a specific location, or across a set 
of locations. 

10 As noted above, the agent -supervisor network 1200 may be 

implemented in a number of ways, including client -server, 
distributed computing architecture and so on. Supervisor 1204 
and entity A 1206, entity B 1208, entity C 1210, entity D 1212 
typically access database 1202 using a Web browser or other 

15 user interface. 

As will be seen, the supervisor 1204 may set up the 
trading board by defining trade rules, the rules as to how the 
trading board may be displayed, and by determining which 
entities are permitted to trade which type of schedules. Once 

20 the trade board is setup, one or more of the agents, in this 
example entity A 1206, entity B 1208, entity C 1210, entity D 
1212, use various displays (as will be described) to post 
their own schedules on the trading board, to view the 
schedules of other entities, to select and trade schedules 

25 with other entities, and to view trades already made. 

As will be seen, if supervisor 1204 has set the trade 
rules to automatically authorize trades, a trade may be 
completed without any supervisor involvement. If, however, 
the supervisor 1204 has set the trade rules to require manual 

30 authorization, the supervisor must review and approve (or 
deny) trades manually. 
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FIGURE 11 illustrates the high level operation of the 
invention, with supervisor tasks shown on the left side of the 
flowchart and agent tasks shown on the right side of the 
flowchart. The particular operations (or any subset of them) 
5 need not be carried in the temporal sequence illustrated in 
FIGURE 11. As illustrated, a supervisor 1102 first sets up 
the trading board by establishing trading rules in step 1104. 
The trading rules preferably are defined in a trading rules 
display (FIGURE 1) , and these rules preferably determine which 

10 trades are allowed and which trades are not allowed. At step 
1106 # supervisor 1102 preferably sets up a trade board display 
(FIGURE 2) that may be used to define the way in which the 
trade board is displayed for agents. At step 1108, supervisor 
1102 sets up an agent permissions display (FIGURE 3) that may 

15 be used to define which agents are permitted to make trades. 
Of course, while only a single supervisor is described in 
connection with the steps of FIGURE 11, this is not a 
limitation. Once supervisor 1102 has set up the trading board 
using trading rules, how the trade board should be displayed, 

20 and the agent permissions display, agents preferably start 
trading schedules . 

In an illustrative example, an agent 1112 selects which 
schedule (s) he or she wishes to post, preferably using a 
"wants to trade" display (FIGURE 5) . This is step 1114. The 

25 agent can then review and confirms the schedule (s) to be 

posted, preferably using a "wants -in- return" screen (FIGURE 6) 
at step 1116. Agent 1112 can view the posted schedules, 
preferably using an agent trade requests display (FIGURE 7) , 
which is step 1118. 

30 Agent 1112 may view the trading board and select 

schedules for trading, preferably using trade board display 
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(FIGURE 8) . This is step 1120. Once agent 1112 has selected 
one or more schedules for trading, he or she can review the 
details of the offered and of fered- in-exchange schedules, 
preferably using a trade details display (FIGURE 9) . This is 
5 step 1122. The agent can then confirm the trade, preferably 
using a confirm trades display (FIGURE 10) , which is step 
1124. 

If supervisor 1102 has set up the trading rules to 
automatically approve trades that meet the defined rules, once 

10 agent 1112 has confirmed a trade, the trade is completed. If, 
however, the supervisor 1102 has set up the trading rules for 
manual approval, once an agent has confirmed a trade, the 
trade preferably has a pending approval status until 
supervisor 1102 approves it, preferably using a supervisor 

15 approval display (FIGURE 4). This is step 1110 in FIGURE 11. 

FIGURES 1-10 illustrate various displays that may be used 
according to the present invention. The particular layout and 
format of a particular display is merely for illustrative 
purposes and is not meant to be taken to limit the scope of 

2 0 the present invention. Moreover, portions of given displays 
may be omitted or modified, or one or more of the various 
displays may be combined in any convenient manner without 
departing from the invention. 

Referring to FIGURE 1, the reference numeral 100 

25 generally designates a trading rules display screen embodying 
an illustrative embodiment of the present invention. 

Trading rules display 100 preferably includes a set of 
control tabs that are selectable to export views of various 
display screens. These tabs include a management unit (MU) 

30 Trade Rules tab (illustrated in Figure 1) , a Trade Board 
Display tab (illustrated in Figure 2) , and an Agent Trade 
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Permissions tab (illustrated in Figure 3) . A "management 
unit" preferably is a set of one or more employees at a given 
level that are managed or manageable by a given entity (e.g., 
a supervisor) collectively. The present invention is not 
5 limited to employee trading in the context of management 

units, of course. One of ordinary skill in the art will also 
appreciate that other display navigation techniques may be 
used in lieu of or in addition to the display tabs shown in 
Figure 1. Further, as used herein, a "supervisor" is any 
10 entity (a person, a machine, a program, or some combination 
thereof) that may .exercise a control function over an entity 
(typically a person) that has a "schedule" associated 
therewith. 

The MU Trade Rules display illustrated in Figure 1 

15 comprises various functions including a Select function 102 
that enables the supervisor to select a given management unit 
(namely, a set of agents) , an Allow function 104 that, if 
selected by the supervisor, enables agents to trade schedules 
online, a Rule- set function 106 that enables a supervisor to 

20 define various trading rules, a Minmax function 108 that 
enables the supervisor to define schedule trading notice 
requirements, and a Fall-in function 110 that enables the 
supervisor to define given time periods (for the assigned 
schedules) that may be traded. For payroll purposes, it may 

25 be desirable to force trades to occur within a given (e.g., 2 
week) window. In this illustrative embodiment, the Select 
function 102 comprises a field 112 for identifying a 
particular MU and a Data Access field 114 that includes a drop 
down listbox with one or more functions such as Modify 

30 (shown) , View, and the like. A Retrieve button 150 is used to 
retrieve previously stored data for a particular management 
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unit. Rule-set function 106 comprises a number of checkboxes: 
approval 116 , same-MU 118 , same-skills 120, same-attribute 
122, give-away 124, partial 126, hours 128, and per 130. The 
Minmax function 108 comprises one or more tillable fields such 
5 as: min-notice 132, max-notice 134, mintime 136 and minunits 
138. The Fall-in function 110 comprises several fillable 
fields such as: week 140, starting-day 142, week-period 144, 
starting-week 146, and month 148. These fields and the 
various field descriptors, of course, are merely illustrative. 

10 As one of ordinary skill in the art will appreciate, the 

trading rules display 100 is the screen a supervisor uses to 
define one or more trading rules by which employees may trade 
their assigned schedules. Using the select function 102, the 
supervisor first enters the management unit (MU) in fill-in 

15 field 112either as a numeric value or as a name, and then he 
or she enters the type of data access, which can have the 
value modify or view; the supervisor then selects a Retrieve 
button 150 to retrieve the rules for the MU specified in MU 
112. In an illustrative embodiment, a supervisor may only 

20 modify an MU for which the supervisor has permission to 

modify. Typically the supervisor will retrieve the rules for 
the purpose of modifying them, so the remaining discussion for 
FIGURE 1 will focus on modifying the rules. 

The Allow function 104 determines whether or not 

25 employees are allowed to trade schedules online. The Rule-set 
106 comprises a plurality of rules with corresponding 
checkboxes. If the checkbox of a rule is checked the rule is 
used, and if it is not checked the rule is not used. 
Preferably, for a given trade to occur, the trade must satisfy 

30 the conditions of all the rules that are checked. For 

example, if rule 1 and rule 2 are checked, then a trade can 
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occur only when rule 1 is satisfied and rule 2 is satisfied. 

The Approval function 116 determines whether or not 
supervisor approval is required for all trades. If approval 
116 is checked, the supervisor must approve all trades, and if 
5 it is not checked, trades are approved automatically if they 
satisfy the rest of the rules . 

The same-MU function 118 determines whether or not agents 
must be in the same MU to trade schedules. Skills 120 
determines whether or not agents must have the same skills to 

10 trade schedules. Skills are typically defined according to 

the requirements of the job(s) that agents are required to do. 
For example, in a contact center, agents may need to have 
bilingual skills, English and Spanish, so "bilingual" might be 
one of the skills required. 

15 The Attribute function 122 preferably is a pull down menu 

with one or more user-defined attributes such as supervisor, 
skill group, etc. When attribute 122 is checked, this user- 
defined attribute must match for both entities wishing to 
trade schedules. 

20 The Give-away function 124 determines whether entities 

can give away a shift, i.e., trade a schedule for nothing in 
return. The Partial checkbox 126 determines whether or not 
partial trades are allowed, i.e.,, whether part of a schedule 
may be exchanged. 

25 The Per fill-in field and/or associated listbox 130 can 

have the value day or week, and when combined with the hours 
fill-in field and/or associated listbox 128, it can be used to 
set a maximum number of hours in a day or week that an entity 
can work if the trade is completed. The same constraints can 

30 be imposed to guarantee minimum values. Thus, for example, if 
the trade exceeds a maximum that is set using hours 128 and 
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per 130, then the trade is not allowed. This is typically 
done if the supervisor wants to limit the amount of overtime 
that an entity will work after the trade is completed. 

The Min-notice fill-in field and/or associated listbox 
5 132 determines a minimum advance notice, preferably expressed 
in number of hours (or any other convenient units) , required 
for a trade. Similarly, a max-notice fill-in field and/or 
associated listbox 134 determines a maximum advance notice, 
preferably expressed in number of days (or any other 

10 convenient units), required for a trade. The Mintime 136 and 
Minunits 138 fill-in fields and/or associated listboxes are 
used to set a minimum of amount of time that can be traded. 
Minunits 138 preferably is a pull-down menu that can have the 
values such as minutes, hours or days. 

15 The Fall-in function 110 allows the supervisor several 

different ways of specifying which time period schedules must 
fall into for the trade to be allowed. A radio button 
preferably is selected or de-selected for this purpose. Thus, 
as illustrated, by selecting the first radio button the 

20 supervisor can specify that traded schedules must fall in a 

same time period, preferably specified by a week fill-in field 
140, and he or she can also specify a start day of the time 
period, specified by a selection from a starting-day listbox 
142 . Alternately, by selecting a second radio button the time 

25 period can be defined as one or more weeks, specified by a 

week-period fill-in field 144, starting with a date, specified 
by selection from a starting-week listbox 146. Another 
alternative available to the supervisor is to check month 
radio button 148 and specify that schedules may only be traded 

30 if they both fall within a same calendar month (or in some 
other convenient time unit such as a payroll reporting 
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period) . 

The Trade Board display tab (once it is selected) is 
illustrated in FIGURE 2. Trading board display rules display 
200 allows the supervisor to determine what information is 
5 displayed on the trade board. If Agent name checkbox 202 is 
selected, the name of the agent posting the schedule is 
displayed. 

If Show attribute checkbox 204 and an attribute selection 
is made from listbox 206, an employee attribute is displayed 

10 on the trade board. Attribute 206 is a user-defined field 
that can be used by the supervisor to choose from a set of 
agent attributes in a pull-down menu. A supervisor may check 
the show attribute checkbox 204 to display a specific agent 
attribute, such as supervisor or skill. 

15 If checkbox 208 is selected, the trade board only shows 

schedules that a logged-in agent is allowed to trade. This 
saves the agent time, as he or she can avoid searching through 
schedules for which he or she cannot trade. Of course, in 
certain circumstances, it may be desirable to allow an agent 

20 to see other agent schedules whether or not he or she can 
trade for those schedules. 

FIGURE 3 illustrates a representative display when the 
Agent Trade Permissions tab (from FIGURE 1) is selected. In 
agent permissions screen 300, the supervisor can determine 

25 which particular agents are permitted to trade schedules. 

Agent data group, field 302, is the same user-defined 
pull -down menu previously discussed in conjunction with 
attribute 206 and attribute 131 of Figure 1. The user can use 
whatever attribute is selected in field 302 to display a table 

30 of all agents having the specified attribute by selecting from 
pull-down menu attribute 302 and then selecting the Retrieve 
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Values button 303. An illustrative table is then displayed as 
shown. 

Agent table 304 is merely representative. It displays an 
agent id 306, an agent name 308, an attribute field 310, and a 
5 checkbox 312 for selecting whether trades should be allowed or 
not allowed for each agent. Note that attribute field 310 
contains the value, such as supervisor name or skill, 
specified in attribute 302. If the checkbox 312 is checked 
for a particular agent, that employee is not allowed to trade 

10 schedules. Of course, the display column may state the 

control function in the affirmative (namely, that trades are 
allowed) , in which case selection of the checkbox would 
indicate that the employee is allowed to trade schedules. As 
illustrated in Figure 3, the table includes a scrollbar to 

15 enable the user to move through the table rapidly. 

Alternatively, control can be expressed on the basis of a 
group of agents. 

Now referring to FIGURE 4, the reference numeral 400 
generally designates a block diagram of a preferred form of 

20 supervisor approval screen. If the supervisor wishes to 

manually approve pending trades, e.g., trades that meet the 
rules specified in trading rules screen 100, then the 
supervisor can display and approve or deny pending trades in 
supervisor approval screen 400. 

25 Supervisor approval screen 400 comprises an Select 

function 402, one or more filters 404, an approve-all control 
button 406, a deny-all control button 408 and a pending-trades 
table 410. Each of these will now be described. 

The Select function 402 allows the supervisor to retrieve 

3 0 and either view or modify pending trades for a specific 

management unit (MU) . This is done by entering or selecting 
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an MU number in MU-number field 412, or by entering an MU name 
in an MU-name field 414 , selecting a type of access, typically 
View or Modify, in a data access field 416, and then selecting 
a Retrieve button 418 to display the selected data. In this 
5 example, the data is illustrated in the table 410, which is 
described below 

Filters 404 allows the retrieved data to be further 
filtered by specifying different criteria. Thus, for example, 
the Request status listbox 420 allows the retrieved 

10 information to be displayed based on the status of the 

requests. Status 420 can have one of several values: All, 
which preferably shows all possible requests; Posted, which 
preferably shows requests posted to the trading board but not 
yet accepted; Pending approval, which preferably shows 

15 requests that have been accepted and are awaiting supervisor 
approval; Approved, which preferably shows trades approved by 
the supervisor but that have not yet been performed; 
Completed, which preferably shows trades that were 
successfully completed; Denied, which preferably shows trades 

20 denied by the supervisor; Failed, which preferably shows 
trades that were approved but then failed for some reason, 
(e.g., such as the scheduled was changed in a way that made 
the trade invalid) ; or Cancelled, which preferably shows 
requests that were posted but then cancelled before any one 

25 accepted them. In the illustrated example, the Request status 
is All, and the Status field 448 shows several of these 
situations. 

The retrieved data can also be filtered by selecting a 
given posting agent using the Posting agent dropdown listbox 
3 0 422, by selecting a given accepting agent using the Accepting 
Agent dropdown listbox 424, by selecting a posted schedule 
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date using a Posted Schedule date listbox 426, or by selecting 
a requested schedule date using a Requested schedule data 
listbox 428. 

Preferably, the supervisor can approve or deny all 
5 displayed trades using an Approve All button 406 or a Deny All 
button 408, respectively. 

Preferably, each entry 410 in the pending- trades table 
430 displays information about the pending trades displayed. 
As illustrated, each trade (identified by the information in a 

10 particular row of the table) may be manually approved or 

denied by the supervisor using an Approve checkbox 432 or a 
Deny checkbox 434. Preferably, the agent id and agent name 
for both the offering and accepting agent are displayed in an 
agent ID column 436 and an agent Name column 438, 

15 respectively. Preferably, date and time information about the 
offered and accepted schedules are also displayed using Day 
column 440, Date column 442, Start time column 444, and End 
time column 446. 

As described above, the Status column 448 displays the 

20 status of the request as filtered by the particular Request 
status 420, and thus displays whether the particular request 
is posted, pending approval, approved, completed, denied, 
failed, or cancelled. Preferably, the name of the supervisor 
who approved or denied the trade is displayed in supervisor 

25 column 450. 

As one of ordinary skill will appreciate, FIGURES 1-4 
describe representative supervisor screens for the inventive 
schedule trading method. Representative agent screens will 
now be described in detail . 

3 0 Referring to FIGURE 5, the reference numeral 500 

generally designates a representative "wants -to- trade" display 
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screen. An agent preferably posts schedules or partial 
schedules to the trading board using the display 500. In this 
illustrated example, the agent may specify the dates of up to 
seven days, e.g., using Day 1 field 502, Day 2 field 504, Day 
5 3 field 506, Day 4 field 508, Day 5 field 510, Day 6 field 512 
and Day 7 field 514 by selecting the day, month, and year for 
the schedule to be posted. Of course, any number of days may 
be used, and there is no requirement that sequential dates be 
entered. Of course, the month and year information can be 
10 separate. 

Preferably, the agent can specify that an entire day is 
to be traded by selecting a full-day radio button 516, or he 
or she may specify that only a specified part of a day is to 
be traded by selecting a partial-day radio button 518 and then 

15 specifying a start time in start-time field 520 and the finish 
time in finish-time field 522. A drop down box is provided to 
set the hours, minutes, and the time of day designations. 

If the agent is satisfied with the schedules selected for 
posting, he or she can select a continue button 524 to move to 

20 a next display screen. If the agent is not satisfied, the he 
or she can select a cancel button 526 to cancel the posting. 

Now referring to FIGURE 6, the reference numeral 600 
generally designates the "wants -in- return" display, which is 
reached when the agent selects the "continue" button 524 in 

25 the first display. 

A first portion 602 of the second display shows the 
schedules the agent has selected for posting on the trade 
board. A second portion of the second display 604 is where 
the agent specifies the schedules the agent wants in exchange 

30 for the agent's posted schedules. The second portion 604 thus 
facilitates the "wants- in-return" function because this 
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portion of the display enables the agent to enter information 
identifying the schedules for which a trade may take place. 
This portion of the display is identified by the u When are you 
willing to work in return?" text, and the various functions of 
5 this display are described in more detail below. 

The agent can post on the trading board by selecting a 
Post my schedule button 606, he or she may return to the 
previous screen (FIGURE 5) and select different schedules to 
post by selecting a Back button 608, or he or she may cancel 

10 the posting by selecting a Cancel button 610. 

As noted above, the first portion 602 of the second 
display shows the schedules selected by the agent in the first 
agent-posting display 500 of FIGURE 5. If the agent wishes to 
change the date selection, he or she can select the change 

15 link 612. 

In the second portion 604 of the display, the agent 
preferably can select one of three options. Using an option 1 
checkbox 614, the agent can offer in exchange to work the same 
dates (in other words, one or more of the same dates as the 

20 agent has posted) but with different start times, in which 

case he or she can then specify that the start times be within 
a given range specified by a start-time fill-in field 616 and 
a start-time fill-in field 618. The agent may also indicate 
that any start time is acceptable by selecting a checkbox any- 

25 time 620. 

By selecting an option 2 checkbox 622, the agent can 
specify that he or she is interested in working on one of his 
or her w off" days, in which case the agent can then specify 
which day(s) by selecting one or more of such days from a day- 

30 off list 624. Preferably, the day-off list 624 has associated 
checkboxes, and this list is populated with dates that are 
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specific to the given agent. In this option, the agent 
preferably may also specify a start time using a start-time 
fill-in field 626 and a start-time fill-in field 628; 
alternatively, the particular agent may indicate that any 
5 start time is acceptable by selecting an any-time checkbox 
630. 

By selecting an option 3 checkbox 632, the agent 
indicates that the posted schedule is being given away and the 
agent therefore does not require anything in return. 

10 Although not illustrated in detail, one of ordinary skill 

will appreciate that the first and second displays shown in 
FIGURES 5-6 may be combined. 

FIGURE 7 generally designates an agent trade requests 
screen that allows an agent to view his or her own trades 

15 using one or more different filters. 

By selecting a posted-trades button 702, the screen 
displays the trades the agent has posted to the board. By 
selecting an accepted- trades button 704, the screen displays 
the trades the agent has accepted. Selecting a post- trades 

20 link 706 allows the agent to go to the screen shown in FIGURE 
5 to post a schedule to the trading board. 

Each trade preferably is displayed using a similar 
format. In particular, preferably trades are grouped together 
based on their status, which as noted above in the illustrated 

25 example includes: posted, pending approval, approved, 

completed, unsuccessful, denied, failed, or cancelled. Trades 
may be displayed in any other convenient grouping or format, 
of course . ( 

A Trade- status field 708 indicates the status of the 

30 trade request. A Hide similar requests link 710 allows the 
user to hide all currently displayed requests that have the 
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same status as the record being displayed. Thus, if trade- 
status 708 is posted, then selection of link 710 will allow 
the user to hide all posted requests that are currently 
displayed. 

5 For each type of trade- status, as noted above requests 

with the same status are preferably listed together. For each 
request, preferably one or more of the following information 
is displayed: the agent's posted schedule is shown in a 
posted- schedule column 712; what the agent is ready to accept 
10 in exchange is shown in an accept -in- return column 714; a 

cancel column 716, which allows the agent to cancel the trade; 
and a details link 718, which allows the agent to view details 
of the trade, and will be discussed in the trade details 
display. 

15 Referring to FIGURE 8, the reference numeral 800 

generally designates trade board display screen that an agent 
uses to view and select one or more schedules for trading. 
This screen comprises a "virtual" bulletin board. 

Schedule table 802 preferably displays all posted 

20 schedules if an all -posted button 804 is selected. Schedule 
table 802 displays all schedules the viewing agent can trade 
if a "schedules I can trade" button 806 is selected. The 
viewing agent can individually select schedules or use a 
check-all link 808 to select all displayed schedules, or he or 

25 she may use a clear-all button 810 to de-select all displayed 
schedules. Once an agent has selected one or more schedules 
to trade, the agent can trade those schedules by selecting a 
trade -schedules button 812, which is an action that preferably 
takes the agent to a confirm trades screen. 

30 As also seen in FIGURE 8, the table 802 preferably 

displays records based on the filters chosen. A record 813 in 
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table 802 (which is a given row) preferably comprises a 
checkbox 814, a show-details link 816 # a posted-by column 818, 
a posted schedule column 820 # and a want -in- return column 822. 
Schedules can be individually selected for trade by selecting 
5 a given checkbox 814 in a given row of the schedule table 802. 
The Posted-by 818 column displays the name of the agent 
posting the schedule. The posted schedule column 820 and the 
want -in -return column 822 display the schedule the posting 
agent is offering and the schedule the posting agent wants in 

10 exchange, respectively. 

An agent can post a schedule by selecting a post -schedule 
link 824. An agent can view the details of a posted schedule 
by selecting a show details link 816 in a given row of the 
table, which takes the agent to the trade details screen as 

15 will be seen. 

Referring now to FIGURE 9, the reference numeral 900 
generally designates a trade details screen that allows an 
agent to view the details of a trade listed in the trade board 
screen. 

20 Trade details screen 900 preferably comprises a "posting 

agent's current schedule" portion 902, a u your current 
schedule" portion 904, and an additional info portion 906. 
The portion 902 preferably shows the actual schedule of the 
agent posting a schedule in exchange, the portion 904 

25 preferably shows the current, pre- trade, schedule (of the 
agent who desires to accept the trade) , and the portion 906 
shows information about the posting agent, such as his or her 
name, supervisor, and the date he or she made the posting. 
As illustrated, the first portion 902 shows the days, 

30 dates and times of the posting agent's schedules for each day 
involved in the potential trade. The "your current schedule" 
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portion 904 shows the days, dates and times of the schedules 
belonging to the agent viewing the schedules for each day 
involved in the trade. Of course, any other convenient way of 
arranging and displaying this data may be implemented. 
5 Referring to FIGURE 10, the reference numeral 1000 

generally designates a confirm trades screen that allows an 
agent to view and confirm trades for schedules selected in the 
trade board display. 

A Chosen- schedules table 1002 preferably displays a 

10 summary of the schedules selected in the trade board display 
800 of FIGURE 8. The first portion 1004 includes a "what- 
you'll-get" column that shows the day, date, start and end 
times, together with an "hours" column that identifies a 
number of hours for the schedule the viewing agent will get in 

15 exchange. A second portion 1006 includes a w what-you' 11-give 
away" column that shows the day, date, start and end times, 
together with an "hours" column that identifies a number of 
hours for the schedule the viewing agent will give in 
exchange, as part of the trade. Of course, these titles and 

20 the various layouts and formats are merely illustrative. 

After reviewing the schedules, the agent can select a 
cancel button 1008 to cancel and return to the trade board 
screen to select a different set of schedules. Alternately, 
the agent can select a confirm button 1010 to confirm the 

25 schedule trades. 

In a particular embodiment, a particular agent operates a 
computer that is connect able to at least one server, with the 
server connectable to a computer network. In a preferred 
embodiment, the server provides a site or a set of pages 

30 (accessible, for example, via the public Internet, via an 
intranet, as an extranet application, or the like) within 
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which given entities (e.g., agents) may post, view and 
negotiate to trade schedules. The server comprises at least 
one processor, a database of schedule information, and code 
executable on the server to enable entities to engage in 
5 schedule trading negotiation. As used herein, a "server" may- 
refer to a given machine, or a set of machines or processes, 
whether centrally- located or distributed. The server also 
includes code for generating the supervisor displays (FIGURES 
1-4) and for exporting views of those displays to client 

10 computers associated with those supervisors. Likewise, the 
server includes code for generating the agent displays 
(FIGURES 5-10) and for exporting views of those displays to 
client computers associated with the agents. 

The present invention provides numerous advantages over 

15 the prior art. In the past, there has been no convenient way 
for employees to "trade" their schedules, or to enable 
supervisors to manage any such process in any meaningful way. 
The virtual bulletin board obviates the time consuming and 
manually intensive process in the prior art where an 

20 supervisor would post a calendar in some accessible locations 
and individual agents would be forced to enter schedules 
manually, or where individual employees would be forced to 
identify and track down potential scheduling trading partners. 
Of course, even in such manual techniques, there was no 

25 ability of the supervisor to easily manage (e.g., approve, 
deny, set up policies) for controlling how such trades 
(assuming they could be found) might be implemented. With the 
present invention, agents that are not handling contacts are 
freed to engage in scheduling searching and trading on the 

30 bulletin board without having to leave their desks. 

The present invention provides a computer- implemented 
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method of work schedule trading. It enables a pair of 
employees, each of whom has a schedule that the other wants, 
to find each other and to conduct a trade easily and 
efficiently. The invention provides an online trade board 
5 where employees can see what trades have been posted, or post 
their own trade requests, without having to search for another 
employee with whom to trade. In addition, the present 
invention ensures that supervisors need not be involved 
unnecessarily when employees want to trade work schedules. 

10 Because rules are defined that prevent employees from 

requesting invalid trades (or trades that the supervisor will 
not authorize) , the supervisor need not be involved until a 
valid match is made (and, as noted above, such trades may even 
be approved automatically, i.e., without any direct supervisor 

15 involvement after the match is made) . 

The present invention allows an employee to indicate what 
schedule he or she would like in return for the schedule he or 
she is posting. For example, an employee may wish to work the 
same day, but just with a different start time; or, however, 

20 the employee may wish to work on one of his or her days off in 
return for the schedule he or she is giving away; or, the 
employee may not want anything in return, in which case he or 
she would end up working fewer hours during the particular 
period. Preferably, another employee would only be able to 

25 accept this trade if he or she has a schedule that the posting 
employee is willing to work. 

Preferably, an employee can accept a schedule trade if he 
or she has a schedule that matches what the posting employee 
is looking for in return. This requirement need not be a 

30 limitation of the invention, however. In an alternative 

embodiment, the posting employee may be given the option of 
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either specifying what he or she would like to work in return, 
accepting whatever the other employee has to give, or waiting 
until a particular trade request is accepted and, at that 
time, deciding whether or not he or she is willing to work the 
5 other employee's schedule. As another variant, the invention 
may enable an employee to post to the trade board information 
about the employee's days off, or information about an 
employee's other free time (e.g., such as lunch time or break 
time) . In this variation, an employee may request a schedule 

10 to work in return for a day off. He or she might post to the 
board his or her lunch or break times, in return for different 
lunch or break times. Another variation is to enable 
employees to trade schedules that are of different lengths. 
In such case, unless an employee is giving his or her posted 

15 schedule away, the two schedules (or schedule segments) that 
are traded preferably are of equal length. A particular agent 
may use the system to trade with himself, such as when he or 
she wants to trade a day off. 

The system may be set up to enable an agent to trade with 

20 a specific agent directly. In such case, a given agent may 
use the trading board to determine who has what schedule 
available and then request a trade with a specific agent 
having that schedule. In this embodiment, the requesting 
agent would initiate a request to the second agent, who 

25 desktop might then open up a popup window stating what the 
requesting agent is offering in return. Alternatively, the 
requesting agent may identify what he or she is looking for 
and cause the system to continually scan for that schedule. 
Once such a schedule is found, the requesting agent is 

3 0 notified, perhaps by email or other notification, that a 

possible trade is available. In this example, the requesting 
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agent might then be provided with an option to accept or 
reject the schedule. 

The present invention need not be limited to trading days 
off, of course. It may be used to enable employees to trade 
5 for special activities (such as slots in a training session) , 
or the like. 

Employees often have ancillary activities scheduled into 
their work day. Thus, a particular employee may have a 
special break time for whatever reason. If desired, the 
10 system may include the ability to include that special 

activity with the schedule being traded. Thus, the agent 
receiving the trade would then get the benefit of the special 
activity. 

Although not meant to be limiting, generally the 
15 schedules being traded will have consistent time periods. 
Thus, for example, an 8.5 hour work schedule is traded for 
another 8.5 hour work schedule. This is not a limitation of 
the invention, however, as it may be desirable to enable 
variations or schedule trades involving unequal time periods 
20 but that are valued as equivalent according to some other 
metric. 

One of ordinary skill will also appreciate that the 
invention can be implemented with supervisor approval required 
for a trade under certain conditions, but not others. 

25 Moreover, some of the above-described functions can be set on 
a per agent basis, as opposed to being set for an agent group. 

As another variant, while the preferred embodiment has 
been illustrated in the context of having agents trade "days/ 
this is not a requirement. The present invention may 

30 facilitate trades in any convenient time periods (less than or 
more than a given day) . 
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Having described our invention, what we claim is as 
follows . 
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